Tile Tick Block
Introduction A tile tick block is a block which can be somehow triggered (for example by powering it by redstone), which uses a tile tick upon triggering to create a delay, and does something after the delay is over. An example for a tile tick block is the redstone torch. When powered it will create a tile tick with a delay of 2 gticks. The tile ticks will be processed every tick and reduce their delay by 1, whenever they get processed. Once a tile tick reaches a delay of 0, it will tell the block it is associated with to do something. In the case of the redstone torch the redstone torch will be turned off after the 2 gticks of tile tick delay. Triggering Due to the processing order of the game, a tile tick will have 1 gtick less delay than normal, if the creation of the tile tick was triggered by an user-input. Otherwise the tile tick will have the base delay shown in the table below upon its creation. Tile Tick Cap If more than 1000 tile ticks finish their delay in one tick, only the 1000 first tile ticks will actually activate their associated blocks. The other tile ticks will wait until they get processed again in the next tick before activating their tile tick block. 'Priority' Attribute Every tile tick has a priority attribute. If two tile ticks finish their delay in the same tick, the tile tick with the lower priority will always update its tile tick block first. If two tile ticks finish their delay in the same tick, and have the same priority, the tile tick which was initially created first will update its tile tick block first. List of all tile tick blocks 1 When an entity collides with a pressure plate, it creates a tile tick. Additionally, whenever the pressure plate gets udpated by a previously created tile tick, it will check whether the entity is still there, and schedule another tile tick if that´s the case. 2 Repeaters and comparators check whether the block they´re facing into is a repeaters or comparator and in some cases change their priorities. Repeaters will have a -3 priority instead of a -1 priority iff facing into another repeater or comparator, and comparators will have a -1 priority instead of a 0 priority iff facing into another repeater or comparator. Additionally, repeaters have a -2 priority instead of a -1 priority, if they´re turning off, and are not facing into another repeater or comparator. However, if a repeater has just turned on, but has no power, the tile tick that will be created to turn the repeater off again will only have a -1 priority instead of -2. 3 When a torch burnout occurs, the torch gets a tile tick with a 160 gtick delay. 4 Lava and Water additionally have a lot of other stuff going on with their delay, which will be explained at a lava and water mechanics page somewhere in the future. The 5 gtick and 30 gtick delay are the standard delay in the overworld. 5 The delay can also be 4, 6 or 8 depending on the setting of the repeater. 6 The same applies to gravel, anvils and dragon eggs. They have a 1 gtick delay before they start falling. 7 The tile ticks created by water and lava will not affect water and lava, but flowing water and flowing lava instead. Additionally, water and lava convert themselves into flowing water and flowing water whenever they get udpated (unless they turn into cobblestone, stone or obsidian). NBT Structure Tile Ticks get stored inside their chunk in a list called TileTicks. Every tile tick is a compound with the following attributes. * String i: The ID of the block the tile tick is associated with. If the tile tick should be inside a block with a different block ID (because the initial block was destroyed or replaced) the tile tick will not affect the block. There are a few exceptions, for example redstone_torch tile ticks can also affect unlit_redstone_torch blocks and vice versa, but I will only create a list of all the exception when I think I know all the exceptions. * int t: The number of ticks until processing should occur. May be negative when processing is overdue. This can happen if the tile tick cap is reached. * int p: The priority of the tile tick. See above. * int x: x position * int y: y position * int z: z position Breaking a tile tick block If a tile tick block created a tile tick, but gets destroyed or changed before the tile tick is over, the tile tick will just stay. The tile tick will not usually affect the new block, because the tile tick remembers the id of the block it wants to affect. If a tile tick block should create a tile tick, and then get replaced by a block with the same block id, the tile tick that the first block created will also affect the second block. Additionally, in some specifically coded cases tile ticks can even affect blocks with a different block id than they should. I don´t know all those cases but I list all I know: Tile ticks cannot distinguish between a redstone_torch and a unlit_redstone_torch block. They also cannot distinguish between unpowered_repeater and powered_repeater, and they cannot distinguish between unpowered_comparator and powered_comparator.